May 91 Letters
Volume Number: 7
Issue Number: 5
Column Tag: Letters
HyperCard Letters 
By Kirk Chase, Editor
Databases views
Paul Whittington
Vice-President
Griffin Software, Inc.
1790 Vermont Dr., Elk Grove, Illinois 60007
708/ 893-7238
I was astonished to learn from Mr. Joseph Terry, Jr. that the first “real”
database has just arrived in the Mac world. I think Oracle Corporation also must be
surprised to hear that they do not have a “real” database.
Mr. Terry writes, “Remember that those old guys and gals really DID know
something.” As one of those old guys with over 15 years of experience in data
processing (that shows you how old I am - I still refer to it as data processing), I have
had experience with databases from mainframes to micros.
In both his letter in the January, 1991 issue of MacTutor and his article in the
February, 1991 issue, Mr. Terry expresses his opinion that a network database model
is the best type of database for “serious” database systems. I think that a more
enlightened opinion is that each database model has its strengths and weaknesses, and
that a database’s appropriateness is dependent on the application employing it.
In a hierarchical database, data is linked from parent to child with the constraint
that each child can have only one parent. The limitation is that you can only
arbitrarily traverse the database from top to bottom. This works well when all of your
data has a one to many relationship and has very few levels in the hierarchy. For
example, an order system might have an order header with name and address
information. Each order header can then point down to a line item for that order. This
causes no problems because the line item is meaningless without the order header.
Hierarchical databases have been around since the late sixties. Network
databases became popular after the Data Base Task Group of the Conference on Data
Systems Languages (CODASYL-DBTG) issued a report defining a data management
system that supports a complete network structure (April 1971). Since Mr. Terry did
a thorough job explaining the network database structure, I won’t repeat that here. The
big advantage that a network database has over a hierarchical one is that a child record
can have more than one parent record and that you can go up and down between children
and parents to your heart’s content. The disadvantage is that it is real easy to get lost in
the database if you are not careful.
The relational database model is based on research done by E.F. Codd. The model
is based on the mathematical foundation of relational algebra, which gets into relations,
domains, degrees, and tuples. A more easily understood description defines a relation as
a table with columns representing fields and rows representing records. Many of
today’s popular databases are built on the relational foundation. The strength of a
relational database is in its ability to extract and combine data in many flexible ways.
Its disadvantage has always been the processing overhead that it imposes.
The best use of a relational database is in situations where you cannot anticipate
the end-user’s needs. A database with sales information is a great example of the need
for a relational database. Marketing people love to aggregate data by weird demographic
information.
Furthermore, no database product conforms exclusively to any one model. Even
Mr. Terry refers to his product as a network database with relational extensions. Every
database product on the market has “extensions” to take advantage of features from
another model.
I think that when we talk about “serious” databases, we are talking multi-user,
client-server stuff. Mr. Terry should look at the Database Access Manager for System
7. This is going to have a huge influence on how applications access databases. It also
defines how a database server must look to its clients and, more specifically, how
Macintosh databases must look to applications.
(And now a word from our sponsor.)
For the past two years Griffin Software has had two database engines for the
Macintosh that use HyperCard as a front end. HyperHIT is based on the hierarchical
database model with a few whiz-bang extensions thrown in. HyperHIT-R is based on
the relational database model. Both are available now through our publisher,
SoftStream International, Inc. Currently in beta is the multi-user version which
supports both HyperHIT and HyperHIT-R files. The expected release date for
HyperHIT-N is the month of April.
Both HyperHIT and HyperHIT-R were designed with HyperCard in mind. They
don’t have fixed length fields. They store data, except for sounds and pictures, as ASCII
text, just as HyperCard does. HyperHIT-R allows for dynamic modifications of the
database structure, without using separate utility programs (importData and
exportData are two of the XCMDs). HyperHIT-R also allows for those bizarre queries
that those marketing people think up. (Can you tell which users give me the most
sleepless nights?) Such as, “all of the people in Illinois, Indiana and Iowa who have
purchased the book DRUG USE IN THE WORKPLACE but have not purchased the book
BODY FLUIDS”.
We would appreciate the opportunity to present an article showing our products’
strengths, as you have afforded to Mr. Terry.
[You are perfectly welcomed and urged to submit an article on your product. In
today’s world, even small products must be strong to compete. Many people have
turned to different aids to help them get more “bang for the buck”. Products like
yours, Mr. Terry’s, MacApp, etc. are all out there for developers to use. Only
desperate developers, though, purchase products they know little about, they do so in
hopes the products will aid their effort. It is therefore imperative to have products
reviewed and advertised.-ed]
Listing Correction
Kirk Chase
MacTutor
The header file “CRemoveLFApp.h” was inadvertently left out of Wade Maxfield’s
article, “Designing With Objects” in the January 1991 MacTutor. Below is the
listing.
/* 1 */
/*****
* CRemoveLFApp.h
*
* Application class for a typical application.
*
*****/
#define _H_CRemoveLFApp /* Include this file only once */
#include
struct CRemoveLFApp : CApplication
{
/* No instance variables */
void IRemoveLFApp(void);
void SetUpFileParameters(void);
void DoCommand(long theCommand);
void Exit(void);
void CreateDocument(void);
void OpenDocument(SFReply *macSFReply);
void Run(void); /* override of built in method */
};
Strip Style FKEY
Thomas Nielsen
Vacaville, CA
Lately, I’ve found myself repeatedly frustrated by the simple operation of
copying and pasting text in HyperCard 2.0. The problem occurs when I go to paste the
text. It seems that HyperCard (many other applications) now copy the style of the text
as well as the text itself. This is great until you have to go to the different menus to set
the font, size, and style. Here is the code for a short little FKEY that strips away the
style from the scrap, leaving only text.
/* 2 */
Handle NewClearSysHandle(long size){
asm{
move.l size,d0
NewHandle CLEAR+SYS
move.l a0,d0
}
}
void main(void){
long scrapsize, offset;
Handle h;
scrapsize=0L;
h=0L;
if (!(h=NewClearSysHandle(0)))
goto returnpoint;
scrapsize=GetScrap(h,'TEXT',&offset);
if (scrapsize>0){
SetHandleSize(h,scrapsize+(scrapsize &1)); /*make Handle even
size*/
ZeroScrap();
PutScrap(scrapsize,'TEXT',*h);
SystemEdit(3); /* Tricky part */
}
returnpoint:
if (h)
DisposHandle(h);
}
See the call to SystemEdit(3)? Well it took me FOREVER to figure that one out.
The system won’t recognize that the scrap has changed until you do it. I hope I’m not the
only programmer out there that’s had problems with this one!
For Think C project
Project type->Code Resource
Type: FKEY (all capitols)
ID: 7 (this is also the number key that invokes FKEY)
Attrs: 20 (purgable)
File Type: rsrc (ResEdit)
Creator: RSED (ResEdit)
Name: Strip Style FKEY
[The full project and listing are included in this month’s source disk.-ed]
Multi-user AppleTalk For HyperCard
Kirk Chase
MacTutor
Epsi Computer Systems, Inc. has announced epsiTalk. This is a development tool
for adding AppleTalk support for HyperCard 2.0. Using epsiTalk, you can incorporate
distributive processing and file serving among network stations. This makes it ideal
for work groups, conferencing, and multi-user applications. There are two versions,
epsiTalk and epsiTalk-EZ selling for $175 and $395 respectively.
EpsiTalk has the ability of creating quick, distributive processing by allowing
you to control other epsiTalk entities on other, idle Macintoshes. It comes equipped
with tools for handling file transfers and access. EpsiTalk also supports aborting and
clearing transmissions midstream.
For more information, contact Robert Eppich or Randy Young at
Epsi Computer Systems, Inc.
209-1255 56th Street
Delta, British Columbia V4L 2B9
Canada
(604) 943-8664